E::ExpList(arg_list) => arg_list.try_into().unwrap(),

Solution: Replaced .unwrap() with proper error handling using match:
E::ExpList(arg_list) => match arg_list.try_into() {
    Ok(arr) => arr,
    Err(_) => {
        context
            .env
            .add_diag(ice!((eloc, "assert! expects 1 or 2 arguments, but got a different number")));
        return error_exp(eloc);
    }
},

Changes:
Fixed 2 locations in hlir/translate.rs (lines ~905 and ~943)
Added test case bad_assert_args to prevent regression
Testing:
assert!(true, 0, 1) now produces a graceful error instead of panic
Valid cases (assert!(true) and assert!(true, 0)) continue to work
Fix 2: PackVariant Field Lookup (Issue #25453)
Problem: The compiler panicked with called Option::unwrap() on a None value when a malformed enum variant declaration (with parser-recovered fields) was used in a PackVariant expression.
Example that caused panic:
module 0x0::T {
    enum E {
        V x{: u8},  // Malformed syntax (missing comma)
    }
    fun f(): E {
        E::V { x: 0 }  // Compiler crashed here
    }
}

Root Cause: In hlir/translate.rs, the code used .unwrap() when looking up fields in the field map:
.map(|(f, (exp_idx, (bt, tf)))| {
    (*field_map.get(&f).unwrap(), f, exp_idx, bt, tf)
})

Solution: Replaced .map().unwrap() with .filter_map() + match:
.filter_map(|(f, (exp_idx, (bt, tf)))| {
    match field_map.get(&f) {
        Some(decl_idx) => Some((*decl_idx, f, exp_idx, bt, tf)),
        None => {
            context.add_diag(diag!(
                TypeSafety::InvalidField,
                (f.loc(), format!(
                    "Invalid field '{}' in enum variant constructor",
                    f.value()
                ))
            ));
            None
        }
    }
})

Changes:
Fixed 1 location in hlir/translate.rs (line ~1455)
Now shows clear error message instead of crashing
Testing:
Malformed enum variants now produce proper error diagnostics
Valid enum variant constructors continue to work correctly
Checklist
[x] Both fixes follow Rust error handling best practices
[x] Error messages are clear and actionable
[x] Valid code continues to compile without issues
[x] Fixes are minimal and focused on the specific issues